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Abstract 


The RSVP ASSOCIATION object was defined in the context of GMPLS- 
controlled Label Switched Paths (LSPs). In this context, the object 
is used to associate recovery LSPs with the LSP they are protecting. 
This object also has broader applicability as a mechanism to 
associate RSVP state. This document defines how the ASSOCIATION 
object can be more generally applied. This document also defines 
Extended ASSOCIATION objects that, in particular, can be used in the 
context of the MPLS Transport Profile (MPLS-TP). This document 
updates RFC 2205, RFC 3209, and RFC 3473. It also generalizes the 
definition of the Association ID field defined in RFC 4872. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6780. 
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Copyright Notice 


Copyright (c) 2012 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


End-to-end and segment recovery are defined for GMPLS-controlled 
Label Switched Paths (LSPs) in [RFC4872] and [RFC4873], respectively. 
Both definitions use the ASSOCIATION object to associate recovery 
LSPs with the LSP they are protecting. Additional narrative on how 
such associations are to be identified is provided in [RFC6689]. 


This document expands the possible usage of the ASSOCIATION object to 


non-GMPLS and non-recovery contexts. The expanded usage applies 
equally to GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209], and non-LSP 
RSVP sessions [RFC2205] [RFC2207] [RFC3175] [RFC4860]. This document 


also reviews how associations should be made in the case in which the 
object is carried in a Path message; additionally, it defines usage 
with Resv messages. This section also discusses usage of the 
ASSOCIATION object outside the context of GMPLS LSPs. 


Some examples of non-LSP association being used to enable resource 
sharing are: 


o Voice Call-Waiting: 


A bidirectional voice call between two endpoints, A and B, is 
signaled using two separate unidirectional RSVP reservations for 
the flows A->B and B->A. If endpoint A wishes to put the A-B call 
on hold and join a separate A-C call, it is desirable that network 
resources on common links be shared between the A-B and A-C calls. 
The B->A and C->A subflows of the call can share resources using 
existing RSVP sharing mechanisms, but only if they use the same 
destination IP addresses and ports. Since by definition, the RSVP 
reservations for the subflows A->B and A->C of the call must have 
different IP addresses in the SESSION objects, this document 
defines a new mechanism to associate the subflows and allow them 
to share resources. 


o Voice Shared Line: 


A voice shared line is a single number that rings multiple 
endpoints (which may be geographically diverse), such as phone 
lines to a manager’s desk and to their assistant. A Voice over IP 
(VoIP) system that models these calls as multiple point-to-point 
unicast pre-ring reservations would result in significantly over- 
counting bandwidth on shared links, since RSVP unicast 
reservations to different endpoints cannot share bandwidth. So, a 
new mechanism is defined in this document to allow separate 
unicast reservations to be associated and to share resources. 
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o Symmetric NAT: 


RSVP permits sharing of resources between multiple flows addressed 
to the same destination D, even from different senders S1 and S2. 
However, if D is behind a NAT operating in symmetric mode 
[RFC5389], it is possible that the destination port of the flows 
S1->D and S2->D may be different outside the NAT. In this case, 
these flows cannot share resources using RSVP, since the SESSION 
objects for these two flows outside the NAT have different 
destination ports. This document defines a new mechanism to 
associate these flows and allow them to share resources. 


In order to support the wider usage of the ASSOCIATION object, this 
document generalizes the definition of the Association ID field 
defined in RFC 4872. This generalization has no impact on existing 
implementations. When using the procedures defined below, 
association is identified based on exact ASSOCIATION object matching. 
Some of the other matching mechanisms defined in RFC 4872, e.g., 
matching based on Session IDs, are not generalized. This document 
allows for, but does not specify, association type-specific 
processing. 


This document also defines the Extended ASSOCIATION objects that can 
be used in the context of MPLS-TP. The scope of the Extended 
ASSOCIATION objects is not limited to MPLS-TP. 


1.1. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


2. Generalized Association ID Field Definition 


The Association ID field is carried in the IPv4 and IPv6 ASSOCIATION 
objects defined in [RFC4872]. The [RFC4872] definition of the field 
reads: 


A value assigned by the LSP head-end. When combined with the 
Association Type and Association Source, this value uniquely 
identifies an association. 


This document allows for the origination of ASSOCIATION objects by 
nodes other than "the LSP head-end". As such, the definition of the 
Association ID field needs to be generalized to accommodate such 
usage. This document defines the Association ID field of the IPv4 
and IPv6 ASSOCIATION objects as: 
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A value assigned by the node that originated the association. 
When combined with the other fields carried in the object, this 
value uniquely identifies an association. 


This change in definition does not impact the procedures or 
mechanisms defined in [RFC4872] or [RFC4873], nor does it impact the 
existing implementations of [RFC4872] or [RFC4873]. 


3. Non-GMPLS and Non-Recovery Usage 


While the ASSOCIATION object [RFC4872] is defined in the context of 
GMPLS recovery, the object can have wider application. [RFC4872] 
defines the object to be used to "associate LSPs with each other", 
and then defines an Association Type field to identify the type of 
association being identified. It also specifies that the Association 
Type field is to be considered when determining association, i.e., 
there may be type-specific association rules. As defined by 
[RFC4872] and reviewed in [RFC6689], this is the case for recovery 
type ASSOCIATION objects. [RFC6689], notably the text related to 
resource sharing types, can also be used as the foundation for a 
generic method for associating LSPs when there is no type-specific 
association defined. 


The remainder of this section defines the general rules to be 
followed when processing ASSOCIATION objects. Object usage in both 
Path and Resv messages is discussed. The usage applies equally to 
GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209], and non-LSP RSVP sessions 
[RFC2205] [RFC2207] [RFC3175] [RFC4860]. As described below, 
association is always done based on matching either Path state to 
Path state, or Resv state to Resv state, but not Path state to Resv 
State. This section applies to the ASSOCIATION objects defined in 
[RFC4872]. 


3.1. Upstream-Initiated Association 


Upstream-initiated association is represented in ASSOCIATION objects 
carried in Path messages and can be used to associate RSVP Path state 
across MPLS Tunnels / RSVP sessions. (Note, per [RFC3209], an MPLS 
tunnel is represented by an RSVP SESSION object, and multiple LSPs 
may be represented within a single tunnel.) Cross-LSP association 
based on Path state is defined in [RFC4872]. This section extends 
that definition by specifying generic association rules and usage for 
non-LSP uses. This section does not modify processing required to 
support [RFC4872] and [RFC4873], which is reviewed in Section 3 of 
[RFC6689]. The use of an ASSOCIATION object in a single session is 
not precluded. 
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3.1.1. Path Message Format 


This section provides the Backus-Naur Form (BNF), see [RFC5511], for 
Path messages containing ASSOCIATION objects. BNF is provided for 
both MPLS and for non-LSP session usage. Unmodified RSVP message 
formats and some optional objects are not listed. 


The formats for MPLS and GMPLS sessions are unmodified from [RFC4872] 
and can be represented based on the BNF in [RFC3209] as: 


<Path Message> ::= <Common Header> [ <INTEGRITY> ] 
<SESSION> <RSVP_HOP> 
<TIME_VALUES> 
[ <EXPLICIT_ROUTE> ] 
<LABEL_ REQUEST> 
[ <SESSION_ATTRIBUTE> ] 
[ <ASSOCIATION> ... ] 
[ <POLICY_DATA> ... ] 
<sender descriptor> 


The format for non-LSP sessions as based on the BNF in [RFC2205] is: 


<Path Message> ::= <Common Header> [ <INTEGRITY> ] 
<SESSION> <RSVP_HOP> 
<TIME_VALUES> 
[ <ASSOCIATION> ... ] 
[ <POLICY_DATA> ... ] 
[ <sender descriptor> ] 


In general, relative ordering of ASSOCIATION objects with respect to 
each other, as well as with respect to other objects, is not 
significant. Relative ordering of ASSOCIATION objects of the same 
type SHOULD be preserved by transit nodes. 


3.1.2. Path Message Processing 


This section is based on, and extends, the processing rules described 
in [RFC4872] and [RFC4873], which is reviewed in [RFC6689]. This 
section applies equally to GMPLS LSPs, MPLS LSPs, and non-LSP session 
state. Note, as previously stated, this section does not modify 
processing required to support [RFC4872] and [RFC4873]. 


A node sending a Path message chooses when an ASSOCIATION object is 
to be included in the outgoing Path message. To indicate association 
between multiple sessions, an appropriate ASSOCIATION object MUST be 
included in the outgoing Path messages corresponding to each of the 
associated sessions. In the absence of Association-Type-specific 
rules for identifying association, the included ASSOCIATION object 
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MUST be identical. When there is an Association-Type-specific 
definition of association rules, the definition SHOULD allow for 
association based on identical ASSOCIATION objects. This document 
does not define any Association-Type-specific rules. (See Section 3 
of [RFC6689] for a review of Association-Type-specific rules derived 
from [RFC4872].) 


When creating an ASSOCIATION object, the originator MUST format the 
object as defined in Section 16.1 of [RFC4872]. The originator MUST 
set the Association Type field based on the type of association being 
identified. The Association ID field MUST be set to a value that 
uniquely identifies the specific association within the context of 
the Association Source field. The Association Source field MUST be 
set to a unique address assigned to the node originating the 
association. 


A downstream node can identify an upstream-initiated association by 
performing the following checks. When a node receives a Path 
message, it MUST check each ASSOCIATION object received in the Path 
message to determine if the object contains an Association Type field 
value supported by the node. For each ASSOCIATION object containing 
a supported association type, the node MUST then check to see if the 
object matches an ASSOCIATION object received in any other Path 
message. To perform this matching, a node MUST examine the Path 
state of all other sessions and compare the fields contained in the 
newly received ASSOCIATION object with the fields contained in the 
Path state’s ASSOCIATION objects. An association is deemed to exist 
when the same values are carried in all fields of the ASSOCIATION 
objects being compared. Type-specific processing of ASSOCIATION 
objects is outside the scope of this document. 


Note that as more than one association may exist, the described 
matching MUST continue after a match is identified and MUST be 
performed against all local Path state. It is also possible for 
there to be no match identified. 


Unless there are type-specific processing rules, downstream nodes 
MUST forward all ASSOCIATION objects received in a Path message in 
any corresponding outgoing Path messages without modification. This 
processing MUST be followed for unknown Association Type field 
values. 


3.2. Downstream-Initiated Association 
Downstream-initiated association is represented in ASSOCIATION 
objects carried in Resv messages and can be used to associate RSVP 


Resv state across MPLS Tunnels/RSVP sessions. Cross-LSP association, 
based on Path state, is defined in [RFC4872]. This section defines 
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cross-session association based on Resv state. This section places 
no additional requirements on implementations supporting [RFC4872] 

and [RFC4873]. Note, the use of an ASSOCIATION object in a single 

session is not precluded. 


3.2.1. Resv Message Format 


This section provides the Backus-Naur Form (BNF), see [RFC5511], for 
Resv messages containing ASSOCIATION objects. BNF is provided for 
both MPLS and for non-LSP session usage. Unmodified RSVP message 
formats and some optional objects are not listed. 


The formats for MPLS, GMPLS, and non-LSP sessions are identical and 
are represented based on the BNF in [RFC2205] and [RFC3209]: 


<Resv Message> ::= <Common Header> [ <INTEGRITY> ] 
<SESSION> <RSVP_HOP> 
<TIME_VALUES> 
[ <RESV_CONFIRM> ] [ <SCOPE> ] 
[ <ASSOCIATION> ... ] 
[ <POLICY_DATA> ... ] 
<STYLE> <flow descriptor list> 


Relative ordering of ASSOCIATION objects with respect to each other, 
as well as with respect to other objects, is not currently 
significant. Relative ordering of ASSOCIATION objects of the same 
type SHOULD be preserved by transit nodes. 


3.2.2. Resv Message Processing 


This section applies equally to GMPLS LSPs, MPLS LSPs, and non-LSP 
session state. 


A node sending a Resv message chooses when an ASSOCIATION object is 
to be included in the outgoing Resv message. A node that wishes to 
allow upstream nodes to associate Resv state across RSVP sessions 
MUST include an ASSOCIATION object in the outgoing Resv messages 
corresponding to the RSVP sessions to be associated. In the absence 
of Association-Type-specific rules for identifying association, the 
included ASSOCIATION objects MUST be identical. When there is an 
Association-Type-specific definition of association rules, the 
definition SHOULD allow for association based on identical 
ASSOCIATION objects. This document does not define any Association- 
Type-specific rules. 


When creating an ASSOCIATION object, the originator MUST format the 


object as defined in Section 16.1 of [RFC4872]. The originator MUST 
set the Association Type field based on the type of association being 
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identified. The Association ID field MUST be set to a value that 
uniquely identifies the specific association within the context of 
the Association Source field. The Association Source field MUST be 
set to a unique address assigned to the node originating the 
association. 


An upstream node can identify a downstream-initiated association by 
performing the following checks. When a node receives a Resv 
message, it MUST check each ASSOCIATION object received in the Resv 
message to determine if the object contains an Association Type field 
value supported by the node. For each ASSOCIATION object containing 
a supported association type, the node MUST then check to see if the 
object matches an ASSOCIATION object received in any other Resv 
message. To perform this matching, a node MUST examine the Resv 
state of all other sessions and compare the fields contained in the 
newly received ASSOCIATION object with the fields contained in the 
Resv state’s ASSOCIATION objects. An association is deemed to exist 
when the same values are carried in all fields of the ASSOCIATION 
objects being compared. Type-specific processing of ASSOCIATION 
objects is outside the scope of this document. 


Note that as more than one association may exist, the described 
matching MUST continue after a match is identified and MUST be 
performed against all local Resv state. It is also possible for 
there to be no match identified. 


Unless there are type-specific processing rules, upstream nodes MUST 
forward all ASSOCIATION objects received in a Resv message in any 
corresponding outgoing Resv messages without modification. This 
processing MUST be followed for unknown Association Type field 
values. 


3.3. Association Types 


Two association types are currently defined: recovery and resource 
sharing. Recovery type association is only applicable within the 


context of recovery [RFC4872] [RFC4873]. Resource sharing is 
applicable to any context and its general use is defined in this 
section. 

3.3.1. Resource Sharing Association Type 


The Resource Sharing Association Type was defined in [RFC4873] and 
was defined within the context of GMPLS and upstream-initiated 
association. This section presents a definition of the resource 
sharing association that allows for its use with any RSVP session 
type and in both Path and Resv messages. This definition is 
consistent with the definition of the resource sharing association 


Berger, et al. Standards Track [Page 9] 


RFC 6780 RSVP Extensions October 2012 


type in [RFC4873] and no changes are required by this section in 
order to support [RFC4873]. The Resource Sharing Association Type 
MUST be supported by any implementation compliant with this document. 


The Resource Sharing Association Type is used to enable resource 
sharing across RSVP sessions. Per [RFC4873], resource sharing uses 
the Association Type field value of 2. ASSOCIATION objects with an 
Association Type with the value Resource Sharing MAY be carried in 
Path and Resv messages. Association for the Resource Sharing type 
MUST follow the procedures defined in Section 3.1.2 for upstream- 
initiated (Path message) association and Section 3.2.1 for 
downstream-initiated (Resv message) association. There are no type- 
specific association rules, processing rules, or ordering 
requirements. Note that, as is always the case with association as 
enabled by this document, no associations are made across Path and 
Resv state. 


Once an association is identified, resources MUST be considered as 
shared across the identified sessions by the admission-control 
function. Since the implementation specifics of the admission- 
control function is outside the scope of RSVP, we observe that how 
resource sharing is actually reflected may vary according to specific 
implementations (e.g., depending on the specific admission-control 
and resource-management algorithm, or on how local policy is taken 
into account). 


3.3.2. Unknown Association Types 


As required by Sections 3.1.2 and 3.2.2 above, a node that receives 
an ASSOCIATION object containing an unknown ASSOCIATION type forwards 
all received ASSOCIATION objects as defined above. The node MAY also 
identify associations per the defined processing, e.g., to make this 
information available via a management interface. 


4. IPv4 and IPv6 Extended ASSOCIATION Objects 


[RFC4872] defines the IPv4 ASSOCIATION object and the IPv6 
ASSOCIATION object. As defined, these objects each contain an 
Association Source field and a 16-bit Association ID field. As 
previously described, the contents of the object uniquely identify an 
association. Because the Association ID field is a 16-bit field, an 
association source can allocate up to 65536 different associations 
and no more. There are scenarios where this number is insufficient 
(for example, where the association identification is best known and 
identified by a fairly centralized entity, and therefore may be 
involved in a large number of associations). 
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An additional case that cannot be supported using the existing 
ASSOCIATION objects is presented by MPLS-TP LSPs. Per [RFC6370], 
MPLS-TP LSPs can be identified based on an operator-unique global 
identifier. As defined in [RFC6370], "global identifier", or 
Global_ID, is based on [RFC5003] and includes the operator’s 
Autonomous System Number (ASN). 


This section defines new ASSOCIATION objects to support extended 
identification in order to address the previously described 
limitations. Specifically, the IPv4 Extended ASSOCIATION object and 
IPv6 Extended ASSOCIATION object are defined below. Both new objects 
include the fields necessary to enable identification of a larger 
number of associations as well as MPLS-TP-required identification. 


The IPv4 Extended ASSOCIATION object and IPv6é Extended ASSOCIATION 
object SHOULD be supported by an implementation compliant with this 
document. The processing rules for the IPv4 and IPv6 Extended 
ASSOCIATION object are described below and are based on the rules for 
the IPv4 and IPv6é ASSOCIATION objects as previously described. 


4.1. IPv4 and IPv6 Extended ASSOCIATION Object Format 


The IPv4 Extended ASSOCIATION object (Class-Num of the form l1lbbbbbb 
with value = 199, C-Type = 3) has the format: 


0 1 2 3 
0 T2 S04 OF 6E TBO Oo OT 2324s B86 PB 90r D2 Be Ae. 6.7) 28) 9-0) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Length | Class-Num(199)| C-Type (3) 
+-+-+-+-+-+-+-+-+-+-+-+-+-++HHHHHH HHHMH 
| Association Type | Association ID 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| IPv4 Association Source | 
t—+t—+—-4+-+-+-4+-+-4+-4+-+-4+-4t-F-4-t ttt OOOHOO OHHO 
| Global Association Source | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Extended Association ID 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
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The IPv6 Extended ASSOCIATION object (Class—-Num of the form 11bbbbbb 
with value = 199, C-Type = 4) has the format: 


0 1 2 3 
OnE G23 425: sO FB Oe OL CDs 3 AS) 6. Ah 8: 0 Le 2:23) A 25? 6: 829-02 AL 
+-4+-4-4-4-4-4-4-4-4-4-4+-4-4-4+-4+-4-4+-4-4+-4-4-4-4+-4-4+-4-4-4-4-4-4-4 


| Length | Class-Num(199)| C-Type (4) 
Fat — tata tata ta tata tata tata tata ta tata tatatatatatatatataitatatatatat 
| Association Type | Association ID 


—+-+4+-4+-4+-+-4+-4+-+-+4+-4+-4+-4+-4-4+-4-4+-4-4+-+4-4-4+-4-4+-4+-4+-+4+-4-4+-+-4+-4-4+ 
IPv6 Association Source 


+ 
| 
| 
| 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Global Association Source | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Extended Association ID 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Association Type: 16 bits 

Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872]. 
Association ID: 16 bits 

Same as for IPv4 and IPv6 ASSOCIATION objects, see Section 2. 
Association Source: 4 or 16 bytes 

Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872]. 
Global Association Source: 4 bytes 

This field contains a value that is a unique global identifier or 

the special value zero (0). When non-zero and not overridden by 

local policy, the Global_ID as defined in [RFC6370] SHALL be used. 

The special value zero indicates that no global identifier is 

present. Use of the special value zero SHOULD be limited to 

entities contained within a single operator. 

If the Global Association Source field value is derived from a 


2-octet ASN, then the two high-order octets of this 4-octet field 
MUST be set to zero. 
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Extended Association ID: variable, 4-byte aligned 


This field contains data that is additional information to support 
unique identification. The length and contents of this field is 
scoped by the Association Source. The length of this field is 
derived from the object Length field and as such MUST have a 
length of zero or be 4-byte aligned. A length of zero indicates 
that this field is omitted. 


Processing 


The processing of an IPv4 or IPv6 Extended ASSOCIATION object MUST be 
identical to the processing of an IPv4 or IPv6 ASSOCIATION object as 
previously described, except as extended by this section. This 
section applies to ASSOCIATION objects included in both Path and Resv 
messages. 


The following are the modified procedures for Extended ASSOCIATION 
object processing: 


(0) 


When creating an Extended ASSOCIATION object, the originator MUST 
format the object as defined in this document. 


The originator MUST set the Association Type, Association ID, and 
Association Source fields as described in Section 4. 


When ASN-based global identification of the Association Source is 
desired, the originator MUST set the Global Association Source 
field. When ASN-based global identification is not desired, the 
originator MUST set the Global Association Source field to zero 
(0). 


The Extended ASSOCIATION object originator MAY include the 
Extended Association ID field. The field is included based on 
local policy. The field MUST be included when the Association ID 
field is insufficient to uniquely identify association within the 
scope of the source of the association. When included, this field 
MUST be set to a value that, when taken together with the other 
fields in the object, uniquely identifies the association being 
identified. 


The object Length field is set based on the length of the Extended 
Association ID field. When the Extended Association ID field is 
omitted, the object Length field MUST be set to 16 or 28 for the 
IPv4 and IPv6 ASSOCIATION objects, respectively. When the 
Extended Association ID field is present, the object Length field 
MUST be set to indicate the additional bytes carried in the 
Extended Association ID field, including pad bytes. 
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Note: Per [RFC2205], the object Length field is set to the total 
object length in bytes, is always a multiple of 4, and is at least 
4. 


The procedures related to association identification are not modified 
by this section. It is important to note that Section 4 defines the 
identification of associations based on ASSOCIATION object matching 
and that such matching, in the absence of type-specific comparison 
rules, is based on the comparison of all fields in an ASSOCIATION 
object. This applies equally to ASSOCIATION objects and Extended 
ASSOCIATION objects. 


5. Compatibility 


Per [RFC4872], the ASSOCIATION object uses an object class number of 
the form llbbbbbb to ensure compatibility with non-supporting nodes. 
Per [RFC2205], such nodes will ignore the object but forward it 
without modification. This is also the action taken for unknown 
association types as discussed above in Section 3.1.2, 3.2.2, and 
S525 


Per [RFC4872], transit nodes that support the ASSOCIATION object but 
not the Extended Association C-Types will "transmit, without 
modification, any received ASSOCIATION object in the corresponding 
outgoing Path message". Per [RFC2205], an egress node that supports 
the ASSOCIATION object but not the Extended Association C-Types, may 
generate an "Unknown object C-Type" error. This error will propagate 
to the ingress node for standard error processing. 


Operators wishing to use a function supported by a particular 
association type should ensure that the type is supported on any node 
that is expected to act on the association. 


6. Security Considerations 


A portion of this document reviews procedures defined in [RFC4872] 
and [RFC4873] and does not define new procedures. As such, no new 
security considerations are introduced in this portion of the 
document. 


Section 3 defines broader usage of the ASSOCIATION object, but does 
not fundamentally expand on the association function that was 
previously defined in [RFC4872] and [RFC4873]. Section 4 increases 
the number of bits that are carried in an ASSOCIATION object (by 32), 
and similarly does not expand on the association function that was 
previously defined. This broader definition does allow for 
additional information to be conveyed, but this information is not 
fundamentally different from the information that is already carried 


Berger, et al. Standards Track [Page 14] 


RFC 6780 RSVP Extensions October 2012 
in RSVP. Therefore, there are no new risks or security 
considerations introduced by this document. 

For a general discussion on MPLS- and GMPLS-related security issues, 
including RSVP’s chain of trust security model, see the MPLS/GMPLS 
security framework [RFC5920]. 


7. IANA Considerations 


IANA has assigned new values for namespaces defined in this document 
and they are summarized in this section. 


7.1. IPv4 and IPv6 Extended ASSOCIATION Objects 


Per this document, IANA has assigned two new C-Types (which are 
defined in Section 3.1) for the existing ASSOCIATION object in the 
"Class Names, Class Numbers, and Class Types" section of the 
"Resource Reservation Protocol (RSVP) Parameters" registry located at 
http://www.iana.org/assignments/rsvp-parameters: 


199 ASSOCIATION [RFC4872] 


Class Types or C-Types 


3 Type 3 IPv4 Extended Association [RFC6780] 
4 Type 4 IPv6 Extended Association [RFC6780] 
7.2. Resource Sharing Association Type 


This document also broadens the potential usage of the Resource 
Sharing Association Type defined in [RFC4873]. As such, IANA has 
updated the reference of the Resource Sharing Association Type 
included in the associated registry. Per this document, IANA has 
also corrected the duplicate usage of ’(R)’ in this registry. In 
particular, the "Association Type" registry found at 
http://www.iana.org/assignments/gmpls-sig-parameters/ has been 
updated as follows: 


OLD 
2 Resource Sharing (R) [RFC4873] 
NEW: 
2 Resource Sharing (S) [RFC4873] [RFC6780] 


There are no other IANA considerations introduced by this document. 
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